...
> Well, there's a better way of representing the transformations in the
> first place. Declare a transform function with the inverse of the
> transforms:
>
> #declare TransFn =
> function {
>     transform {
>         ...your transforms...
>         invert
>     }
> }
>
> isosurface {
>     function {
>         f_isosurface_box(
>             TransFn(x, y, z).x,
>             TransFn(x, y, z).y,
>             TransFn(x, y, z).z
>         )
>     }
>     ...
>
> Of course, this is less efficient than it could be, since you can't
> declare variables or handle vectors, but it's certainly easier to handle
> and more efficient at handling lots of transformations. You could write
> macros to create separate functions for the x, y, and z coordinates
> which might be more efficient...
>
> #macro XTransFn(Trans)
>     #local TransFn = function {transform {Trans}}
>     #local C0 = TransFn(0, 0, 0);
>     #local CX = TransFn(1, 0, 0) - C0;
>     #local CY = TransFn(0, 1, 0) - C0;
>     #local CZ = TransFn(0, 0, 1) - C0;
>     function {x*CX.x + y*CY.x + z*CZ.x + C0.x}
> #end
>
> And similarly for y and z...a smarter macro could remove zero terms to
> speed calculation. This macro would be used like this:
>
> #declare f_RotateX = XTransFn(transform {rotate ...})
>
...
Thanks for your reply. I don't completly understand all that you sugested,
but it gives me a few things to look into. Will have to play with the code
for awhile :-)

Stephen

Post a reply to this message